home *** CD-ROM | disk | FTP | other *** search
Text File | 1993-06-07 | 42.4 KB | 1,473 lines |
-
-
-
-
- Definitions of Managed Objects for
- Source Routing Bridges
-
-
- Thu May 27 12:31:20 EST 1993
-
-
- Draft Expiration Date: November 1993
-
-
- Eric B. Decker
- cisco Systems, Inc.
- cire@cisco.com
-
-
- Keith McCloghrie
- Hughes LAN Systems, Inc.
- kzm@hls.com
-
-
- Paul Langille & Anil Rijsinghani
- Digital Equipment Corporation
- anil@levers.enet.dec.com
- langille@edwin.enet.dec.com
-
-
- Status of this Memo
-
- This document is an Internet Draft. Internet Drafts are
- working documents of the Internet Engineering Task Force
- (IETF), its Areas, and its Working Groups. Note that other
- groups may also distribute working documents as Internet
- Drafts.
-
- Internet Drafts are valid for a maximum of six months and may
- be updated, replaced, or obsoleted by other documents at any
- time. It is inappropriate to use Internet Drafts as reference
- material or to cite them other than as a "work in progress".
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- 1. Introduction
-
- This memo defines an experimental portion of the Management
- Information Base (MIB) for use with network management
- protocols in TCP/IP based internets. In particular it defines
- objects for managing source routing bridges.
-
- The MIB was originally published in RFC 1286 section 4.1.3 as
- "The dot1dSr Group." IEEE 802.5 revised its addendum to RFC
- 802.1(d) several times since the original MIB was published,
- and in the process also changed its MIB. For procedural
- reasons, the group was split apart from the main MIB, allowing
- the major portion of the Bridge MIB to advance in the
- standards process largely unchanged, while the Source Routing
- Group iterated at the Proposed Standard step. Implementors
- are advised to consider the two documents together.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 2]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- 2. The Network Management Framework
-
- The Internet-standard Network Management Framework consists of
- three components. They are:
-
- o RFC 1155 which defines the SMI, the mechanisms used for
- describing and naming objects for the purpose of
- management. RFC 1212 defines a more concise description
- mechanism, which is wholly consistent with the SMI.
-
- o RFC 1213 defines MIB-II, the core set of managed objects
- for the Internet suite of protocols.
-
- o RFC 1157 which defines the SNMP, the protocol used for
- network access to managed objects.
-
- The Framework permits new objects to be defined for the
- purpose of experimentation and evaluation.
-
-
- 2.1. Object Definitions
-
- Managed objects are accessed via a virtual information store,
- termed the Management Information Base or MIB. Objects in the
- MIB are defined using the subset of Abstract Syntax Notation
- One (ASN.1) defined in the SMI. In particular, each object
- object type is named by an OBJECT IDENTIFIER, an
- administratively assigned name. The object type together with
- an object instance serves to uniquely identify a specific
- instantiation of the object. For human convenience, we often
- use a textual string, termed the descriptor, to refer to the
- object type.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 3]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- 3. Overview
-
- A common device present in many networks is the Bridge. This
- device is used to connect Local Area Network segments below
- the network layer. There are two major modes defined for this
- bridging; transparent and source route. The transparent
- method of bridging is defined in the IEEE 802.1d MAC Bridge
- specification [11]. Source route bridging has been defined by
- I.B.M. and is described in the Token Ring Architecture
- Reference[12], as well as the IEEE 802.5M SRT Bridge
- Operations Addendum [14] to 802.1d. This memo defines objects
- needed for management of a source routing bridge, and is an
- extension to the SNMP Bridge MIB [7].
-
- The SNMP Bridge MIB defines objects which must be implemented
- by all bridges, as well as objects needed for management of
- transparent bridges.
-
- To be consistent with IAB directives and good engineering
- practice, an explicit attempt was made to keep this MIB as
- simple as possible. This was accomplished by applying the
- following criteria to objects proposed for inclusion:
-
- (1) Start with a small set of essential objects and add only
- as further objects are needed.
-
- (2) Require objects be essential for either fault or
- configuration management.
-
- (3) Consider evidence of current use and/or utility.
-
- (4) Limit the total of objects.
-
- (5) Exclude objects which are simply derivable from others in
- this or other MIBs.
-
- (6) Avoid causing critical sections to be heavily
- instrumented. The guideline that was followed is one
- counter per critical section per layer.
-
-
- 3.1. Structure of MIB
-
- Objects in this MIB are arranged into groups. Each group is
- organized as a set of related objects. The overall structure
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 4]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- and assignment of objects to their groups is shown below.
- Where appropriate the corresponding IEEE 802.1d[11] and IEEE
- 802.5M [14] management object name is also included.
-
- SR Bridge MIB Name IEEE 802.5M Name
-
- dot1dSr
- PortTable
- Port
- HopCount SourceRoutingPort
- .PortHopCount
- LocalSegment .SegmentNumber
- BridgeNum .BridgeNumber
- TargetSegment
- LargestFrame .LargestFrameSize
- STESpanMode .LimitedBroadcastMode
- SpecInFrames BridgePort
- .ValidSRFramesReceived
- SpecOutFrames .ValidSRForwardedOutbound
- ApeInFrames
- ApeOutFrames .BroadcastFramesForwarded
- SteInFrames
- SteOutFrames .BroadcastFramesForwarded
- SegmentMismatchDiscards .DiscardInvalidRI
- DuplicateSegmentDiscards .LanIdMismatch
- HopCountExceededDiscards .FramesDiscardedHopCountExceeded
-
-
- The following IEEE management objects have not been included
- in the SR Bridge MIB for the indicated reasons.
-
-
- IEEE Object Disposition
-
- SourceRoutingPort
- The following objects were NOT
- included in this MIB because they are
- redundant or not considered useful.
- .LimitedBroadcastEnable
- .DiscardLackOfBuffers
- .DiscardErrorDetails
- .DiscardTargetLANInoperable
- .ValidSRDiscardedInbound
- .BroadcastBytesForwarded
- .NonBroadcastBytesForwarded
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 5]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- .FramesNotReceivedDueToCongestion
- .FramesDiscardedDueToInternalError
-
- 3.1.1. The dot1dSr Group
-
- This group contains the objects that describe the entity's
- state with respect to source route bridging. If source
- routing is not supported this group will not be implemented.
- This group is applicable to source route only, and SRT
- bridges.
-
- 3.2. Relationship to Other MIBs
-
- As described above, some IEEE 802.1d management objects have
- not been included in this MIB because they overlap with
- objects in other MIBs applicable to a bridge implementing this
- MIB. In particular, it is assumed that a bridge implementing
- this MIB will also implement (at least) the Bridge MIB and the
- 'system' group and the 'interfaces' group defined in MIB-II
- [6].
-
- 3.2.1. Relationship to the Bridge MIB
-
- The Bridge MIB [7] must be implemented by all bridges,
- including transparent, SR and SRT bridges. The SR bridge MIB
- is an extension to the Bridge MIB.
-
-
- 3.2.2. Relationship to the 'system' group
-
- In MIB-II, the 'system' group is defined as being mandatory
- for all systems such that each managed entity contains one
- instance of each object in the 'system' group. Thus, those
- objects apply to the entity as a whole irrespective of whether
- the entity's sole functionality is bridging, or whether
- bridging is only a subset of the entity's functionality.
-
-
- 3.2.3. Relationship to the 'interfaces' group
-
- In MIB-II, the 'interfaces' group is defined as being
- mandatory for all systems and contains information on an
- entity's interfaces, where each interface is thought of as
- being attached to a `subnetwork'. (Note that this term is not
- to be confused with `subnet' which refers to an addressing
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 6]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- partitioning scheme used in the Internet suite of protocols.)
- The term 'segment' is used in this memo to refer to such a
- subnetwork.
-
- Implicit in this MIB is the notion of ports on a bridge. Each
- of these ports is associated with one interface of the
- 'interfaces' group, and in most situations, each port is
- associated with a different interface. However, there are
- situations in which multiple ports are associated with the
- same interface. An example of such a situation would be
- several ports each corresponding one-to-one with several X.25
- virtual circuits but all on the same interface.
-
- Each port is uniquely identified by a port number. A port
- number has no mandatory relationship to an interface number,
- but in the simple case a port number will have the same value
- as the corresponding interface's interface number. Port
- numbers are in the range (1..dot1dBaseNumPorts).
-
- Some entities perform other functionality as well as bridging
- through the sending and receiving of data on their interfaces.
- In such situations, only a subset of the data sent/received on
- an interface is within the domain of the entity's bridging
- functionality. This subset is considered to be delineated
- according to a set of protocols, with some protocols being
- bridged, and other protocols not being bridged. For example,
- in an entity which exclusively performed bridging, all
- protocols would be considered as being bridged, whereas in an
- entity which performed IP routing on IP datagrams and only
- bridged other protocols, only the non-IP data would be
- considered as being bridged.
-
- Thus, this MIB (and in particular, its counters) are
- applicable only to that subset of the data on an entity's
- interfaces which is sent/received for a protocol being
- bridged. All such data is sent/received via the ports of the
- bridge.
-
-
- 4. Changes from RFC 1286
-
- In addition to being separated from the Bridge MIB into a
- separate document, the following changes were implemented as a
- result of feedback from IEEE 802.5M:
-
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 7]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- (1) Changed syntax of dot1dSrPortLargestFrame to INTEGER in
- order to allow for having 64 possible values as described
- in draft 7 of the SR Addendum. Listed all legal values
- in description.
-
- (2) Updated syntax of dot1dSrPort, used to index into
- dot1dSrPortTable, to use the range (1..65535).
-
- (3) Added a counter to dot1dSrPortTable to count occurences
- of duplicate LAN IDs or Tree errors.
-
- (4) Added a counter to dot1dSrPortTable to count LAN ID
- mismatches.
-
- (5) Added text to dot1dSrPortSpecInFrames and
- dot1dSrPortSpecOutFrames clarifying that they are also
- referred to as Source Routed Frames.
-
- (6) Added text to dot1dSrPortApeInFrames and
- dot1dSrPortApeOutFrames clarifying that they are also
- referred to as All Routes Explorer frames.
-
- (7) Added a scalar variable to dot1dSr to indicate the
- largest frame that may pass through the bridge.
-
- (8) Added a scalar variable to dot1dSr to indicate whether
- the bridge uses 3 bit or 6 bit length ngotiation fields.
-
- (9) Added dot1dPortPairTableSize to indicate the size of the
- following table.
-
- (10) Added dot1dPortPairGroup to allow representation of port
- pairs as defined in the IEEE 802.5M SRT Addendum.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 8]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- 5. Definitions
-
-
- RFCxxxx-MIB DEFINITIONS ::= BEGIN
-
- IMPORTS
- Counter, Gauge
- FROM RFC1155-SMI
- dot1dBridge, dot1dSr
- FROM RFCBRIDGE-MIB -- to be replaced by DS
- -- ver. of Bridge MIB RFC
- OBJECT-TYPE
- FROM RFC-1212;
-
-
-
- -- groups in the SR MIB
-
- -- dot1dSr is imported from the Bridge MIB
-
- dot1dPortPair OBJECT IDENTIFIER ::= { dot1dBridge 10 }
- -- use 10, to be safe
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 9]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- -- the dot1dSr group
-
- -- this group is implemented by those bridges that
- -- support the source route bridging mode, including Source
- -- Routing and SRT bridges.
-
-
- dot1dSrPortTable OBJECT-TYPE
- SYNTAX SEQUENCE OF Dot1dSrPortEntry
- ACCESS not-accessible
- STATUS mandatory
- DESCRIPTION
- "A table that contains information about every
- port that is associated with this source route
- bridge."
- ::= { dot1dSr 1 }
-
- dot1dSrPortEntry OBJECT-TYPE
- SYNTAX Dot1dSrPortEntry
- ACCESS not-accessible
- STATUS mandatory
- DESCRIPTION
- "A list of information for each port of a source
- route bridge."
- INDEX { dot1dSrPort }
- ::= { dot1dSrPortTable 1 }
-
- Dot1dSrPortEntry ::=
- SEQUENCE {
- dot1dSrPort
- INTEGER,
- dot1dSrPortHopCount
- INTEGER,
- dot1dSrPortLocalSegment
- INTEGER,
- dot1dSrPortBridgeNum
- INTEGER,
- dot1dSrPortTargetSegment
- INTEGER,
- dot1dSrPortLargestFrame
- INTEGER,
- dot1dSrPortSTESpanMode
- INTEGER,
- dot1dSrPortSpecInFrames
- Counter,
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 10]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- dot1dSrPortSpecOutFrames
- Counter,
- dot1dSrPortApeInFrames
- Counter,
- dot1dSrPortApeOutFrames
- Counter,
- dot1dSrPortSteInFrames
- Counter,
- dot1dSrPortSteOutFrames
- Counter,
- dot1dSrPortSegmentMismatchDiscards
- Counter,
- dot1dSrPortDuplicateSegmentDiscards
- Counter,
- dot1dSrPortHopCountExceededDiscards
- Counter,
- dot1dSrPortDupLanIdOrTreeErrors
- Counter,
- dot1dSrPortLanIdMismatches
- Counter
- }
-
- dot1dSrPort OBJECT-TYPE
- SYNTAX INTEGER (1..65535)
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "The port number of the port for which this entry
- contains Source Route management information."
- ::= { dot1dSrPortEntry 1 }
-
- dot1dSrPortHopCount OBJECT-TYPE
- SYNTAX INTEGER
- ACCESS read-write
- STATUS mandatory
- DESCRIPTION
- "The maximum number of routing descriptors allowed
- in an All Paths or Spanning Tree Explorer frames."
- ::= { dot1dSrPortEntry 2 }
-
- dot1dSrPortLocalSegment OBJECT-TYPE
- SYNTAX INTEGER
- ACCESS read-write
- STATUS mandatory
- DESCRIPTION
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 11]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- "The segment number that uniquely identifies the
- segment to which this port is connected. Current
- source routing protocols limit this value to the
- range: 0 through 4095. A value of 65535 signifies
- that no segment number is assigned to this port."
- ::= { dot1dSrPortEntry 3 }
-
- dot1dSrPortBridgeNum OBJECT-TYPE
- SYNTAX INTEGER
- ACCESS read-write
- STATUS mandatory
- DESCRIPTION
- "A bridge number uniquely identifies a bridge when
- more than one bridge is used to span the same two
- segments. Current source routing protocols limit
- this value to the range: 0 through 15. A value of
- 65535 signifies that no bridge number is assigned
- to this bridge."
- ::= { dot1dSrPortEntry 4 }
-
- dot1dSrPortTargetSegment OBJECT-TYPE
- SYNTAX INTEGER
- ACCESS read-write
- STATUS mandatory
- DESCRIPTION
- "The segment number that corresponds to the target
- segment this port is considered to be connected to
- by the bridge. Current source routing protocols
- limit this value to the range: 0 through 4095. A
- value of 65535 signifies that no target segment is
- assigned to this port."
- ::= { dot1dSrPortEntry 5 }
-
- -- It would be nice if we could use ifMtu as the size of the
- -- largest frame, but we can't because ifMtu is defined to be
- -- the size that the (inter-)network layer can use which can
- -- differ from the MAC layer (especially if several layers of
- -- encapsulation are used).
-
- dot1dSrPortLargestFrame OBJECT-TYPE
- SYNTAX INTEGER
- ACCESS read-write
- STATUS mandatory
- DESCRIPTION
- "The maximum size of the INFO field (LLC and
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 12]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- above) that this port can send/receive. It does
- not include any MAC level (framing) octets. The
- value of this object is used by this bridge to
- determine whether a modification of the
- LargestFrame (LF, see [14]) field of the Routing
- Control field of the Routing Information Field is
- necessary.
-
- 64 valid values are defined by the IEEE 802.5M SRT
- Addendum: 516, 635, 754, 873, 993, 1112, 1231,
- 1350, 1470, 1542, 1615, 1688, 1761, 1833, 1906,
- 1979, 2052, 2345, 2638, 2932, 3225, 3518, 3812,
- 4105, 4399, 4865, 5331, 5798, 6264, 6730, 7197,
- 7663, 8130, 8539, 8949, 9358, 9768, 10178, 10587,
- 10997, 11407, 12199, 12992, 13785, 14578, 15370,
- 16163, 16956, 17749, 20730, 23711, 26693, 29674,
- 32655, 35637, 38618, 41600, 44591, 47583, 50575,
- 53567, 56559, 59551, and 65535.
-
- Behavior of the port when an illegal value is
- written is implementation specific. It is
- recommended that a reasonable legal value be
- chosen."
- ::= { dot1dSrPortEntry 6 }
-
- dot1dSrPortSTESpanMode OBJECT-TYPE
- SYNTAX INTEGER {
- auto-span(1),
- disabled(2),
- forced(3)
- }
- ACCESS read-write
- STATUS mandatory
- DESCRIPTION
- "Determines how this port behaves when presented
- with a Spanning Tree Explorer frame. The value
- 'disabled(2)' indicates that the port will not
- accept or send Spanning Tree Explorer packets; any
- STE packets received will be silently discarded.
- The value 'forced(3)' indicates the port will
- always accept and propagate Spanning Tree Explorer
- frames. This allows a manually configured
- Spanning Tree for this class of packet to be
- configured. Note that unlike transparent bridging
- this is not catastrophic to the network if there
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 13]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- are loops. The value 'auto-span(1)' can only be
- returned by a bridge that both implements the
- Spanning Tree Protocol and has use of the protocol
- enabled on this port. The behavior of the port for
- Spanning Tree Explorer frames is determined by the
- state of dot1dStpPortState. If the port is in the
- 'forwarding' state, the frame will be accepted or
- propagated. Otherwise it will be silently
- discarded."
- ::= { dot1dSrPortEntry 7 }
-
- dot1dSrPortSpecInFrames OBJECT-TYPE
- SYNTAX Counter
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "The number of Specifically Routed frames, also
- referred to as Source Routed Frames, that have
- been received from this port's segment."
- ::= { dot1dSrPortEntry 8 }
-
- dot1dSrPortSpecOutFrames OBJECT-TYPE
- SYNTAX Counter
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "The number of Specifically Routed frames, also
- referred to as Source Routed Frames, that this
- port has transmitted on its segment."
- ::= { dot1dSrPortEntry 9 }
-
- dot1dSrPortApeInFrames OBJECT-TYPE
- SYNTAX Counter
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "The number of All Paths Explorer frames, also
- referred to as All Routes Explorer frames, that
- have been received by this port from its segment."
- ::= { dot1dSrPortEntry 10 }
-
- dot1dSrPortApeOutFrames OBJECT-TYPE
- SYNTAX Counter
- ACCESS read-only
- STATUS mandatory
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 14]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- DESCRIPTION
- "The number of all Paths Explorer Frames, also
- referred to as All Routes Explorer frames, that
- have been transmitted by this port on its
- segment."
- ::= { dot1dSrPortEntry 11 }
-
- dot1dSrPortSteInFrames OBJECT-TYPE
- SYNTAX Counter
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "The number of spanning tree explorer frames that
- have been received by this port from its segment."
- ::= { dot1dSrPortEntry 12 }
-
- dot1dSrPortSteOutFrames OBJECT-TYPE
- SYNTAX Counter
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "The number of spanning tree explorer frames that
- have been transmitted by this port on its
- segment."
- ::= { dot1dSrPortEntry 13 }
-
- dot1dSrPortSegmentMismatchDiscards OBJECT-TYPE
- SYNTAX Counter
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "The number of explorer frames that have been
- discarded by this port because the routing
- descriptor field contained an invalid adjacent
- segment value."
- ::= { dot1dSrPortEntry 14 }
-
- dot1dSrPortDuplicateSegmentDiscards OBJECT-TYPE
- SYNTAX Counter
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "The number of frames that have been discarded by
- this port because the routing descriptor field
- contained a duplicate segment identifier."
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 15]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- ::= { dot1dSrPortEntry 15 }
-
- dot1dSrPortHopCountExceededDiscards OBJECT-TYPE
- SYNTAX Counter
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "The number of explorer frames that have been
- discarded by this port because the Routing
- Information Field has exceeded the maximum route
- descriptor length."
- ::= { dot1dSrPortEntry 16 }
-
- dot1dSrPortDupLanIdOrTreeErrors OBJECT-TYPE
- SYNTAX Counter
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "The number of duplicate LAN IDs or Tree errors.
- This helps in detection of problems in networks
- containing older IBM Source Routing Bridges."
- ::= { dot1dSrPortEntry 17 }
-
- dot1dSrPortLanIdMismatches OBJECT-TYPE
- SYNTAX Counter
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "The number of cases where a frame was forwarded,
- but the 'from' LAN ID was incorrect."
- ::= { dot1dSrPortEntry 18 }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 16]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- -- some scalar objects in dot1dSr
-
- dot1dSrBridgeLargestFrame OBJECT-TYPE
- SYNTAX INTEGER
- ACCESS read-write
- STATUS mandatory
- DESCRIPTION
- "The maximum size of the INFO field (LLC and
- above) that may pass through this bridge. The
- possible values as the same as for
- dot1dSrPortLargestFrame."
- ::= { dot1dSr 2 }
-
- dot1dSrBridgeLfMode OBJECT-TYPE
- SYNTAX INTEGER {
- mode3(1),
- mode6(2)
- }
- ACCESS read-write
- STATUS mandatory
- DESCRIPTION
- "Indicates whether the bridge operates using older
- 3 bit length negotiation fields or the newer 6 bit
- length field in its RIF."
- ::= { dot1dSr 3 }
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 17]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- -- The Port-Pair Database
-
- -- Implementation of this group is optional.
-
- -- This group is implemented by those bridges that support the
- -- direct multiport model of the source route bridging mode as
- -- defined in the IEEE 802.5 SRT Addendum to 802.1d.
-
-
- dot1dPortPairTableSize OBJECT-TYPE
- SYNTAX Gauge
- ACCESS read-only
- STATUS mandatory
- DESCRIPTION
- "The total number of entries in the Bridge Port
- Pair Database."
- ::= { dot1dPortPair 1 }
-
-
- -- the Bridge Port-Pair table
-
- -- this table represents port pairs within a bridge forming
- -- a unique bridge path, as defined in the IEEE 802.5M SRT
- -- Addendum.
-
- dot1dPortPairTable OBJECT-TYPE
- SYNTAX SEQUENCE OF Dot1dPortPairEntry
- ACCESS not-accessible
- STATUS mandatory
- DESCRIPTION
- "A table that contains information about every
- port pair database entity associated with this
- source routing bridge."
- ::= { dot1dPortPair 2 }
-
- dot1dPortPairEntry OBJECT-TYPE
- SYNTAX Dot1dPortPairEntry
- ACCESS not-accessible
- STATUS mandatory
- DESCRIPTION
- "A list of information for each port pair entity
- of a bridge."
- INDEX { dot1dPortPairLowPort, dot1dPortPairHighPort }
- ::= { dot1dPortPairTable 1 }
-
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 18]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- Dot1dPortPairEntry ::=
- SEQUENCE {
- dot1dPortPairLowPort
- INTEGER,
- dot1dPortPairHighPort
- INTEGER,
- dot1dPortPairBridgeNum
- INTEGER,
- dot1dPortPairBridgeState
- INTEGER
- }
-
- dot1dPortPairLowPort OBJECT-TYPE
- SYNTAX INTEGER (1..65535)
- ACCESS read-write
- STATUS mandatory
- DESCRIPTION
- "The port number of the lower numbered port for
- which this entry contains port pair database
- information."
- ::= { dot1dPortPairEntry 1 }
-
- dot1dPortPairHighPort OBJECT-TYPE
- SYNTAX INTEGER (1..65535)
- ACCESS read-write
- STATUS mandatory
- DESCRIPTION
- "The port number of the higher numbered port for
- which this entry contains port pair database
- information."
- ::= { dot1dPortPairEntry 2 }
-
- dot1dPortPairBridgeNum OBJECT-TYPE
- SYNTAX INTEGER
- ACCESS read-write
- STATUS mandatory
- DESCRIPTION
- "A bridge number that uniquely identifies the path
- provided by this source routing bridge between the
- segments connected to dot1dPortPairLowPort and
- dot1dPortPairHighPort. The purpose of bridge
- number is to disambiguate between multiple paths
- connecting the same two LANs."
- ::= { dot1dPortPairEntry 3 }
-
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 19]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- dot1dPortPairBridgeState OBJECT-TYPE
- SYNTAX INTEGER {
- enabled(1),
- disabled(2),
- invalid(3)
- }
- ACCESS read-write
- STATUS mandatory
- DESCRIPTION
- "The state of dot1dPortPairBridgeNum. Writing
- 'invalid(3)' to this object removes the
- corresponding entry."
- ::= { dot1dPortPairEntry 4 }
-
-
-
-
- END
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 20]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- 6. Acknowledgments
-
- This document was produced on behalf of the Bridge Sub-Working
- Group of the SNMP Working Group of the Internet Engineering
- Task Force.
-
- The authors wish to thank the members of the Bridge Working
- Group for their many comments and suggestions which improved
- this effort. In particular, Fred Baker (chairman of the
- working group) of ACC, Steve Sherry of Xyplex, Frank
- Kastenholz of Clearpoint Research Corp, and Richard Sweatt of
- Synoptics who was also IEEE 802.5's designated liaison to this
- WG in drafting this SR MIB. Others members of the Bridge
- Working Group who contributed to this effort are:
-
- Bill Anderson, Mitre
- Karl Auerbach, Epilogue
- Fred Baker, ACC (chair)
- Terry Bradley, Wellfleet
- Ted Brunner, Bellcore
- Jeffrey Buffum, Apollo
- Chris ChioTasso, Fibronics
- Anthony Chung, HLS
- Chuck Davin, MIT-LCS
- Andy Davis, Spider
- Eric Decker, cisco
- Nadya El-Afandi, Network Systems
- Gary Ellis,HP/Apollo
- Richard Fox, SynOptics
- Stan Froyd, ACC
- Frank Kastenholz, Clearpoint Research
- Shirnshon Kaufman,
- Jim Kinder, Fibercom
- Cheryl Krupczak,NCR
- Paul Langille, Digital
- Peter Lin,Vitalink
- Keith McCloghrie, HLS
- Donna McMaster, SynOptics
- Dave Perkins, 3Com
- Jim Reinstedler, Ungermann Bass
- Anil Rijsinghani, Digital
- Mark Schaefer, David Systems
- Steve Sherry, Xyplex
- Bob Stewart, Xyplex
- Emil Sturniolo,
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 21]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- Richard Sweatt, SynOptics
- Kevin Synott, Retix
- Ian Thomas, Chipcom
- Maurice Turcott, Racal
- Fei Xu
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 22]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- 7. References
-
- [1] V. Cerf, IAB Recommendations for the Development of
- Internet Network Management Standards. Internet Working
- Group Request for Comments 1052. Network Information
- Center, SRI International, Menlo Park, California,
- (April, 1988).
-
- [2] V. Cerf, Report of the Second Ad Hoc Network Management
- Review Group, Internet Working Group Request for Comments
- 1109. Network Information Center, SRI International,
- Menlo Park, California, (August, 1989).
-
- [3] M.T. Rose and K. McCloghrie, Structure and Identification
- of Management Information for TCP/IP-based internets,
- Internet Working Group Request for Comments 1155.
- Network Information Center, SRI International, Menlo
- Park, California, (May, 1990).
-
- [4] K. McCloghrie and M.T. Rose, Management Information Base
- for Network Management of TCP/IP-based internets,
- Internet Working Group Request for Comments 1156.
- Network Information Center, SRI International, Menlo
- Park, California, (May, 1990).
-
- [5] J.D. Case, M.S. Fedor, M.L. Schoffstall, and J.R. Davin,
- Simple Network Management Protocol, Internet Working
- Group Request for Comments 1157. Network Information
- Center, SRI International, Menlo Park, California, (May,
- 1990).
-
- [6] K. McCloghrie and M.T. Rose (editors), Management
- Information Base for Network Management of TCP/IP-based
- internets: MIB-II, Internet Working Group Request for
- Comments 1213. Network Information Center, SRI
- International, Menlo Park, California, (March, 1991).
-
- [7] E. Decker, P. Langille, A. Rijsinghani, and K. McCloghrie
- Definitions of Managed Objects for Bridges, Internet
- Draft work in progress, (May, 1993). [Update reference
- to DS ver of Bridge MIB --agr]
-
- [8] Specification of Abstract Syntax Notation One (ASN.1),
- International Organization for Standardization.
- International Standard 8824, (December, 1987).
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 23]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- [9] Information processing systems - Open Systems
- Interconnection - Specification of Basic Encoding Rules
- for Abstract Notation One (ASN.1), International
- Organization for Standardization. International Standard
- 8825, (December, 1987).
-
- [10] M.T. Rose, K. McCloghrie (editors), Concise MIB
- Definitions, Internet Working Group Request for Comments
- 1212. Network Information Center, SRI International,
- Menlo Park, California, (March, 1991).
-
- [11] M.T. Rose (editor), A Convention for Defining Traps for
- use with the SNMP, Internet Working Group Request for
- Comments 1215. Network Information Center, SRI
- International, Menlo Park, California, (March, 1991).
-
- [12] ANSI/IEEE Standard 802.1D-1990 MAC Bridges, IEEE Project
- 802 Local and Metropolitan Area Networks, (March 8,
- 1991).
-
- [13] I.B.M. Token Ring Architecture Reference
-
- [14] ISO DIS 10038 MAC Bridges
-
- [15] ANSI/IEEE P802.5M-Draft 7, Source Routing Transparent
- Bridge Operation, IEEE Project 802 (1991).
-
- [16] ANSI/IEEE 802.1y, Source Routing Tutorial for End System
- Operation, (September, 1990)
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 24]
-
-
-
-
-
- Internet Draft Source Routing Bridge MIB May 1993
-
-
- Table of Contents
-
-
- 1 Introduction .......................................... 2
- 2 The Network Management Framework ...................... 3
- 2.1 Object Definitions .................................. 3
- 3 Overview .............................................. 4
- 3.1 Structure of MIB .................................... 4
- 3.1.1 The dot1dSr Group ................................. 6
- 3.2 Relationship to Other MIBs .......................... 6
- 3.2.1 Relationship to the Bridge MIB .................... 6
- 3.2.2 Relationship to the 'system' group ................ 6
- 3.2.3 Relationship to the 'interfaces' group ............ 6
- 4 Changes from RFC 1286 ................................. 7
- 5 Definitions ........................................... 9
- 5.1 Groups in the SR MIB ................................ 9
- 5.2 The dot1dSr Group Definitions ....................... 10
- 5.3 The dot1dPortPair Group Definitions ................. 18
- 6 Acknowledgments ....................................... 21
- 7 References ............................................ 23
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Decker/McCloghrie/Langille/Rijsinghani [Page 25]
-
-